It would appear that SER v0.8.12 is performing URI matching against the INVITE line rather than the To: header. This appears to cause problems with Snom phones. Below is the initial INVITE request sent by a Snom 200:
INVITE sip:172.21.30.53 SIP/2.0..Via: SIP/2.0/UDP 172.21.20.89:5060;branch= z9hG4bK-d4iq2xxwsyff..Route: sip:5803932@172.21.30.53;user=phone..From: " xxxxxx" sip:IC89@172.21.30.53;tag=tf5tyz77r1..To: <sip:5803932@172.21.30. 53;user=phone>..Call-ID: 3c267820f20d-hj2ilvrq6eoj@172-21-20-89..CSeq: 1 IN VITE..Max-Forwards: 70..Contact: sip:IC89@172.21.20.89:5060;line=1..User- Agent: snom200-2.02t..Accept-Language: en..Accept: application/sdp..Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE , INFO..Supported: timer, 100rel, replaces..Session-Expires: 7200..Content- Type: application/sdp..Content-Length: 270....v=0..o=root 9679 9679 IN IP4 172.21.20.89..s=SIP Call..c=IN IP4 172.21.20.89..t=0 0..m=audio 10010 RTP/A VP 0 8 3 18 97..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/ 8000..a=rtpmap:18 g729/8000..a=rtpmap:97 telephone-event/8000..a=fmtp:97 0- 15..a=sendrecv..
The SER configuration has the following directive:
if (uri=~"^sip:580[0-9][0-9][0-9][0-9]@") { log(1, "Local call sent to gateway"); rewritehost("172.21.30.51"); t_relay(); break; };
This fails to match the above request even though the To: header in the above request contains the necessary pattern. This same configuration works fine with a Cisco phone, but it's INVITE request contains the a complete URI:
INVITE sip:5803932@172.21.30.51 SIP/2.0..Max-Forwards: 10..Record-Route: <s ip:5803932@172.21.30.53;ftag=f2be0b0014cdf23a7f153-5b3b8b0b;lr=on>..Via: SI P/2.0/UDP 172.21.30.53;branch=z9hG4bK72cc.024d7ee4.0..Via: SIP/2.0/UDP 172. 21.20.225:5060..From: "IC225" sip:IC225@172.21.30.53;tag=f2be0b0014cdf23a 7f153-5b3b8b0b..To: sip:5803932@172.21.30.53..Call-ID: 000bbef2-df4c0003- 6004eb37-6333d578@172.21.20.225..Date: Thu, 04 Dec 2003 20:42:51 GMT..CSeq: 101 INVITE..Expires: 180..User-Agent: Cisco-SIP-IP-Phone/2..Accept: applic ation/sdp..Contact: sip:IC225@172.21.20.225:5060..Content-Type: application /sdp..Content-Length: 222....v=0..o=CiscoSystemsSIP-IPPhone-UserAgent 8030 16590 IN IP4 172.21.20.225..s=SIP Call..c=IN IP4 172.21.20.225..t=0 0..m=au dio 26274 RTP/AVP 0 8 18 96..a=rtpmap:0 pcmu/8000..a=rtpmap:96 telephone-ev ent/8000..a=fmtp:96 0-11..
Is there anything I can change in the ser.cfg to instruct SER to match against the To: header?
On Thu, Dec 04, 2003 at 02:12:36PM -0700, Jamin W. Collins wrote:
It would appear that SER v0.8.12 is performing URI matching against the INVITE line rather than the To: header.
I've just confirmed that this behavior is indeed different than 0.8.10. I've rolled the servers back to 0.8.10, for now.
On Dec 04, 2003 at 17:11, Jamin W. Collins jcollins@asgardsrealm.net wrote:
On Thu, Dec 04, 2003 at 02:12:36PM -0700, Jamin W. Collins wrote:
It would appear that SER v0.8.12 is performing URI matching against the INVITE line rather than the To: header.
I've just confirmed that this behavior is indeed different than 0.8.10. I've rolled the servers back to 0.8.10, for now.
As Jiri said, ser always matched URI against request URIs and not To. This behaviour never changed (I wrote the uri matching iand it is the same from ser 0.0.1).
What's happening in your case, is snom uses a preloaded route ser, with the proper uri in it. Cisco sends it directly as the request uri.
Do you use route processing before uri matching in both scripts? (0.8.10 & 0.8.12)
I think you use it 0.8.10, but I'm not sure you do so in 0.8.12.
Andrei
On Fri, Dec 05, 2003 at 10:29:06AM +0100, Andrei Pelinescu-Onciul wrote:
On Dec 04, 2003 at 17:11, Jamin W. Collins wrote:
I've just confirmed that this behavior is indeed different than 0.8.10. I've rolled the servers back to 0.8.10, for now.
As Jiri said, ser always matched URI against request URIs and not To. This behaviour never changed (I wrote the uri matching iand it is the same from ser 0.0.1).
What's happening in your case, is snom uses a preloaded route ser, with the proper uri in it. Cisco sends it directly as the request uri.
Do you use route processing before uri matching in both scripts? (0.8.10 & 0.8.12)
I think you use it 0.8.10, but I'm not sure you do so in 0.8.12.
I've forwared both configurations to Jiri. I tried to keep the logic essentially the same between versions. It's quite possible that I've missed something between the two, but I certainly don't see what. I'm going to gather ngrep dumps of calls from the different versions.
At 10:12 PM 12/4/2003, Jamin W. Collins wrote:
It would appear that SER v0.8.12 is performing URI matching against the INVITE line rather than the To: header. This appears to cause problems with Snom phones. Below is the initial INVITE request sent by a Snom 200:
INVITE sip:172.21.30.53 SIP/2.0..Via: SIP/2.0/UDP 172.21.20.89:5060;branch= z9hG4bK-d4iq2xxwsyff..Route: sip:5803932@172.21.30.53;user=phone..From: " xxxxxx" sip:IC89@172.21.30.53;tag=tf5tyz77r1..To: <sip:5803932@172.21.30. 53;user=phone>..Call-ID: 3c267820f20d-hj2ilvrq6eoj@172-21-20-89..CSeq: 1 IN VITE..Max-Forwards: 70..Contact: sip:IC89@172.21.20.89:5060;line=1..User- Agent: snom200-2.02t..Accept-Language: en..Accept: application/sdp..Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE , INFO..Supported: timer, 100rel, replaces..Session-Expires: 7200..Content- Type: application/sdp..Content-Length: 270....v=0..o=root 9679 9679 IN IP4 172.21.20.89..s=SIP Call..c=IN IP4 172.21.20.89..t=0 0..m=audio 10010 RTP/A VP 0 8 3 18 97..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/ 8000..a=rtpmap:18 g729/8000..a=rtpmap:97 telephone-event/8000..a=fmtp:97 0- 15..a=sendrecv..
The SER configuration has the following directive:
if (uri=~"^sip:580[0-9][0-9][0-9][0-9]@") { log(1, "Local call sent to gateway"); rewritehost("172.21.30.51"); t_relay(); break; };This fails to match the above request even though the To: header in the above request contains the necessary pattern. This same configuration works fine with a Cisco phone, but it's INVITE request contains the a complete URI:
INVITE sip:5803932@172.21.30.51 SIP/2.0..Max-Forwards: 10..Record-Route: <s ip:5803932@172.21.30.53;ftag=f2be0b0014cdf23a7f153-5b3b8b0b;lr=on>..Via: SI P/2.0/UDP 172.21.30.53;branch=z9hG4bK72cc.024d7ee4.0..Via: SIP/2.0/UDP 172. 21.20.225:5060..From: "IC225" sip:IC225@172.21.30.53;tag=f2be0b0014cdf23a 7f153-5b3b8b0b..To: sip:5803932@172.21.30.53..Call-ID: 000bbef2-df4c0003- 6004eb37-6333d578@172.21.20.225..Date: Thu, 04 Dec 2003 20:42:51 GMT..CSeq: 101 INVITE..Expires: 180..User-Agent: Cisco-SIP-IP-Phone/2..Accept: applic ation/sdp..Contact: sip:IC225@172.21.20.225:5060..Content-Type: application /sdp..Content-Length: 222....v=0..o=CiscoSystemsSIP-IPPhone-UserAgent 8030 16590 IN IP4 172.21.20.225..s=SIP Call..c=IN IP4 172.21.20.225..t=0 0..m=au dio 26274 RTP/AVP 0 8 18 96..a=rtpmap:0 pcmu/8000..a=rtpmap:96 telephone-ev ent/8000..a=fmtp:96 0-11..
Is there anything I can change in the ser.cfg to instruct SER to match against the To: header?
SER has always matched against request URI and that's the proper thing to do. The INVITE above should be processed using Route processing, as for example in default script.
-jiri
On Fri, Dec 05, 2003 at 01:48:15AM +0100, Jiri Kuthan wrote:
SER has always matched against request URI and that's the proper thing to do. The INVITE above should be processed using Route processing, as for example in default script.
Testing the same configuration (adjusted for syntax changes) with 0.8.10 and 0.8.12 reveals that the two versions handle the request differently. With 0.8.10, the request is rewritten and forwarded to 172.21.30.51 with 0.8.12 it is not.
Section 2.2.2.2 example 2-7 of the Admin guide[1] shows almost exactly the syntax and matching I'm trying to use.
Additionally, your statement doesn't explain why the same config would work for the Cisco but not the Snom. They both have the same To: request, but different INVITE lines. The Snom request is forwarded based on the configuration's default rather than the above special condition, while the Cisco's is handled by the special condition as I would have expected both to be. I can provide full configuration files and ngrep's for test's from both phones with both 0.8.10 and 0.8.12, if it would help.
[1] - http://iptel.org/ser/doc/seruser/seruser.html
At 04:23 AM 12/5/2003, Jamin W. Collins wrote:
On Fri, Dec 05, 2003 at 01:48:15AM +0100, Jiri Kuthan wrote:
SER has always matched against request URI and that's the proper thing to do. The INVITE above should be processed using Route processing, as for example in default script.
Testing the same configuration (adjusted for syntax changes) with 0.8.10 and 0.8.12 reveals that the two versions handle the request differently. With 0.8.10, the request is rewritten and forwarded to 172.21.30.51 with 0.8.12 it is not.
config file similarity does not imply that either of them is correct. As I told previously, your script apparently ignored Route processing. Why it worked for one telephone and not for some other one may or may not be related to their use of preloaded Routes, but that's just a quick guess.
-jiri
Audiocodes?
I am playing with a MP-108. It is an Audiocodes box with 8 FXS ports. I have it registering, and placing calls (sort of). However, when I try to call it, it acts like it isn't seeing the invite....when I call out, it sets up the call, then acts like it doesn't see the OK:
Here is the OK: # U 2003/12/04 21:27:32.334206 216.87.144.203:5060 -> 66.228.53.207:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 66.228.53.207;branch=z9hG4bKacNzOTHDl. From: Gateway sip:9723937976@addaline.com;tag=1c1574720137. To: sip:2143357976@addaline.com;tag=4ADC0734-1EA3. Date: Fri, 05 Dec 2003 03:27:24 GMT. Call-ID: 157472013720137YmWO-9723937976--2143357976@66.228.53.207. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 34108 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:92143357976@216.87.144.196:5060. Record-Route: sip:2143357976@216.87.144.203;ftag=1c1574720137;lr. Content-Type: application/sdp. Content-Length: 221. . v=0. o=CiscoSystemsSIP-GW-UserAgent 1796 7474 IN IP4 216.87.144.196. s=SIP Call. c=IN IP4 216.87.144.196. t=0 0. m=audio 18602 RTP/AVP 0 19. c=IN IP4 216.87.144.196. a=rtpmap:0 PCMU/8000. a=rtpmap:19 CN/8000. a=ptime:20.
The audio codes is completely ignoring it. it gets sent several times then the gateway gives up. I know the SER server and MP-108 are communicating, because it REGISTERs fine. It is almost like the MP-108 doesn't like something about the packet so it chooses to ignore it, but I cannot find a status error message anywhere....
Does anyone have the MP-10X working?
Any ideas?
---gre
A little more information I gathered, the Cisco gateway is sending a packet, the syslog output for audiocodes is saying:
StackMngr: Message was not Parsed correctly ! Last parsed line was :AllowHeader : 1070601384 1624 godzillaa-206.august.net ( lgr_stk_mngr)(437 ) !! [ERROR] The error was = Unexpected input 1070601384 1624 godzillaa-206.august.net ( lgr_stk_mngr)(438 ) !! [ERROR] The Line of the error was = 9 1070601384 1624 godzillaa-206.august.net ( lgr_stk_mngr)(439 ) !! [ERROR] The Column of the error was = 10
Doesn't tell me much, except that the error might be around the Allow: stuff. So, I did notice the allow line is: Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO.
Kinda long, the audio codes might be having problems, so I did:
replace("Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO.", "Allow: INVITE, ACK, CANCEL, BYE, OPTIONS.");
as the first line in my script....but I'm still sending the entire string to the audiocodes. Am I filtering wrong? The replace statement is almost the first line of my route{} script.
---greg
Greg Fausak wrote:
Audiocodes?
I am playing with a MP-108. It is an Audiocodes box with 8 FXS ports. I have it registering, and placing calls (sort of). However, when I try to call it, it acts like it isn't seeing the invite....when I call out, it sets up the call, then acts like it doesn't see the OK:
Here is the OK: # U 2003/12/04 21:27:32.334206 216.87.144.203:5060 -> 66.228.53.207:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 66.228.53.207;branch=z9hG4bKacNzOTHDl. From: Gateway sip:9723937976@addaline.com;tag=1c1574720137. To: sip:2143357976@addaline.com;tag=4ADC0734-1EA3. Date: Fri, 05 Dec 2003 03:27:24 GMT. Call-ID: 157472013720137YmWO-9723937976--2143357976@66.228.53.207. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 34108 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:92143357976@216.87.144.196:5060. Record-Route: sip:2143357976@216.87.144.203;ftag=1c1574720137;lr. Content-Type: application/sdp. Content-Length: 221. . v=0. o=CiscoSystemsSIP-GW-UserAgent 1796 7474 IN IP4 216.87.144.196. s=SIP Call. c=IN IP4 216.87.144.196. t=0 0. m=audio 18602 RTP/AVP 0 19. c=IN IP4 216.87.144.196. a=rtpmap:0 PCMU/8000. a=rtpmap:19 CN/8000. a=ptime:20.
The audio codes is completely ignoring it. it gets sent several times then the gateway gives up. I know the SER server and MP-108 are communicating, because it REGISTERs fine. It is almost like the MP-108 doesn't like something about the packet so it chooses to ignore it, but I cannot find a status error message anywhere....
Does anyone have the MP-10X working?
Any ideas?
---gre
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Thu, 4 Dec 2003, Greg Fausak wrote:
Audiocodes?
I am playing with a MP-108. It is an Audiocodes box with 8 FXS ports.
[...]
The audio codes is completely ignoring it. it gets sent several times then the gateway gives up. I know the SER server and MP-108 are communicating, because it REGISTERs fine. It is almost like the MP-108 doesn't like something about the packet so it chooses to ignore it, but I cannot find a status error message anywhere....
Does anyone have the MP-10X working?
I've been testing an MP-104 (4 fxo ports) and they don't really work very well... Audiocodes has sent me 4 different software versions after fixing some reported bugs and with the last version you can register and place calls but still not very stable.
The software version is:
Boot file name = ramMP108_SIP_873.cmp
Saludos JesusR.
------------------------------- Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------
Jesus,
Thanks for the input!
I worked with the AudioCodes for several hours yesterday. It has some problems. I can get it to register, but I cannot get it to originate or terminate a phone call to my PSTN gateway. It does originate calls to other UA devices.
My debugging session included turning on the syslog feature of the MP-108. Here is an example of the error I see in the log:
2003.12.04 22:35:15 godzillaa-206 ( lgr_stk_mngr)(234 ) !! [ERROR] StackMngr: Message was not Parsed correctly ! Last parsed line was :AllowHeader : 2003.12.04 22:35:15 godzillaa-206 ( lgr_stk_mngr)(235 ) !! [ERROR] The error was = Unexpected input 2003.12.04 22:35:15 godzillaa-206 ( lgr_stk_mngr)(236 ) !! [ERROR] The Line of the error was = 9 2003.12.04 22:35:15 godzillaa-206 ( lgr_stk_mngr)(237 ) !! [ERROR] The Column of the error was = 10
I also captured the packets as they went by, here is the packet that triggered the message above:
# U 2003/12/04 22:35:15.205420 216.87.144.196:5060 -> 216.87.144.203:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 216.87.144.203;branch=z9hG4bKf819.798ade57.0,SIP/2.0/UDP 66.228.53.207;branch=z9hG4bKacRuFEzdB. From: Gateway sip:9723937976@66.228.53.207;tag=1c-1376639640. To: sip:9723236598@216.87.144.203;tag=4B1A0D04-1586. Date: Fri, 05 Dec 2003 04:35:09 GMT. Call-ID: 291832765627656NWXe-9723937976--9723236598@66.228.53.207. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 15138 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:99723236598@216.87.144.196:5060. Record-Route: sip:9723236598@216.87.144.203;ftag=1c-1376639640;lr. Content-Type: application/sdp. Content-Length: 219. . v=0. o=CiscoSystemsSIP-GW-UserAgent 676 309 IN IP4 216.87.144.196. s=SIP Call. c=IN IP4 216.87.144.196. t=0 0. m=audio 18862 RTP/AVP 0 19. c=IN IP4 216.87.144.196. a=rtpmap:0 PCMU/8000. a=rtpmap:19 CN/8000. a=ptime:20.
I do not know how AudioCodes counts, from 0 or 1, but, if the counting is from zero then line ten is:
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO.
This is produced by my Cisco 7206 VXR with 12.3.1(a) IOS. This looks to be valid. This packet is the result of an internal INVITE by the AudioCodes (can't make an outbound call). The same thing happens with an incoming call from the PSTN.
---greg
Jesus Rodriguez wrote:
On Thu, 4 Dec 2003, Greg Fausak wrote:
Audiocodes?
I am playing with a MP-108. It is an Audiocodes box with 8 FXS ports.
[...]
The audio codes is completely ignoring it. it gets sent several times then the gateway gives up. I know the SER server and MP-108 are communicating, because it REGISTERs fine. It is almost like the MP-108 doesn't like something about the packet so it chooses to ignore it, but I cannot find a status error message anywhere....
Does anyone have the MP-10X working?
I've been testing an MP-104 (4 fxo ports) and they don't really work very well... Audiocodes has sent me 4 different software versions after fixing some reported bugs and with the last version you can register and place calls but still not very stable.
The software version is:
Boot file name = ramMP108_SIP_873.cmp
Saludos JesusR.
Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305
-
Andrei Pelinescu-Onciul -
Greg Fausak -
Jamin W. Collins -
Jesus Rodriguez -
Jiri Kuthan