Hi Greg,
looks like you will have to start debugging :-)
Normally, SER doesn't care of payload (you could do H.323 tunnelling in it if you wished ;-)) I can only imagine SER can complain about the message if it uses some SDP-mangling module like nathelper but even then i would not expect SER dropping silently. Let me know what you have found out in any case -- it looks like a perfectly legitimate SIP request.
-jiri
At 07:44 14/06/2006, Greg Fausak wrote:
Before I start debugging I thought I'd ask. I have a sip message from a gateway (Cisco IOS) that is being sliently dropped. Should ser be able to handle a message that looks like this? I haven't done a multipart message before.
Thanks, ---greg
INVITE sip:+19194724170@sn-sip-in.ca-sn1.cisco.com:5060 SIP/2.0 Via: SIP/2.0/UDP 172.18.109.91:5060;branch=z9hG4bK4F0109C Remote-Party-ID: sip: +19199915651@172.18.109.91;party=calling;screen=yes;privacy=off From: sip:+19199915651@172.18.109.91;tag=249E4980-FFC To: sip:+19194724170@sn-sip-in.ca-sn1.cisco.com Date: Tue, 13 Jun 2006 19:37:55 GMT Call-ID: F241878C-FA4A11DA-81EFC5C8-2F1D7951@172.18.109.91 Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 4064260884-4199158234-2157445126-1397050494 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Max-Forwards: 10 Timestamp: 1150227475 Contact: sip:+19199915651@172.18.109.91:5060 Expires: 180 Allow-Events: telephone-event Content-Type: multipart/mixed;boundary=uniqueBoundary Mime-Version: 1.0 Content-Length: 797
--uniqueBoundary Content-Type: application/sdp Content-Disposition: session;handling=required
v=0 o=CiscoSystemsSIP-GW-UserAgent 8340 2382 IN IP4 172.18.109.91 s=SIP Call c=IN IP4 172.18.109.91 t=0 0 m=audio 19122 RTP/AVP 18 3 0 4 100 101 c=IN IP4 172.18.109.91 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=fmtp:4 annexa=yes a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
--uniqueBoundary Content-Type: application/gtd Content-Disposition: signal;handling=optional
IAM, PRN,isdn*,,NI***, USI,rate,c,s,c,1 USI,lay1,ulaw TMR,00 CPN,02,,1,4724170 CGN,04,,1,y,2,9199915651 CPC,09 FCI,,,,,,,y, GCI,f23fb314fa4a11da8098000653454c7e
--uniqueBoundary--
-- Greg Fausak greg@thursday.com _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Indeed it is a valid message as the SIP RFC states in section 7.4.1 that multipart is a valid payload, the Nortel CS1K and related switches all generate multipart SDP to transport proprietary attributes along with the standard SDP.
The big problem with using multipart, however, is that the RFC also states "Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart." but implementations like Nortel's ONLY send multipart and have no fall back.
Jiri's right though, the only thing in SER that will have problems with this type of message are the nathelper and mediaproxy modules when you try to analyze and fixup the SDP.
-Evan
P.S. We recently submitted a patch to the Asterisk project that added support for multipart SDP so if anyone is using Asterisk in conjunction with devices that generate multipart SDP they will now interop correctly.
Jiri Kuthan wrote:
Hi Greg,
looks like you will have to start debugging :-)
Normally, SER doesn't care of payload (you could do H.323 tunnelling in it if you wished ;-)) I can only imagine SER can complain about the message if it uses some SDP-mangling module like nathelper but even then i would not expect SER dropping silently. Let me know what you have found out in any case -- it looks like a perfectly legitimate SIP request.
-jiri
At 07:44 14/06/2006, Greg Fausak wrote:
Before I start debugging I thought I'd ask. I have a sip message from a gateway (Cisco IOS) that is being sliently dropped. Should ser be able to handle a message that looks like this? I haven't done a multipart message before.
Thanks, ---greg
INVITE sip:+19194724170@sn-sip-in.ca-sn1.cisco.com:5060 SIP/2.0 Via: SIP/2.0/UDP 172.18.109.91:5060;branch=z9hG4bK4F0109C Remote-Party-ID: sip: +19199915651@172.18.109.91;party=calling;screen=yes;privacy=off From: sip:+19199915651@172.18.109.91;tag=249E4980-FFC To: sip:+19194724170@sn-sip-in.ca-sn1.cisco.com Date: Tue, 13 Jun 2006 19:37:55 GMT Call-ID: F241878C-FA4A11DA-81EFC5C8-2F1D7951@172.18.109.91 Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 4064260884-4199158234-2157445126-1397050494 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Max-Forwards: 10 Timestamp: 1150227475 Contact: sip:+19199915651@172.18.109.91:5060 Expires: 180 Allow-Events: telephone-event Content-Type: multipart/mixed;boundary=uniqueBoundary Mime-Version: 1.0 Content-Length: 797
--uniqueBoundary Content-Type: application/sdp Content-Disposition: session;handling=required
v=0 o=CiscoSystemsSIP-GW-UserAgent 8340 2382 IN IP4 172.18.109.91 s=SIP Call c=IN IP4 172.18.109.91 t=0 0 m=audio 19122 RTP/AVP 18 3 0 4 100 101 c=IN IP4 172.18.109.91 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=fmtp:4 annexa=yes a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
--uniqueBoundary Content-Type: application/gtd Content-Disposition: signal;handling=optional
IAM, PRN,isdn*,,NI***, USI,rate,c,s,c,1 USI,lay1,ulaw TMR,00 CPN,02,,1,4724170 CGN,04,,1,y,2,9199915651 CPC,09 FCI,,,,,,,y, GCI,f23fb314fa4a11da8098000653454c7e
--uniqueBoundary--
-- Greg Fausak greg@thursday.com _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Evan Borgström -
Jiri Kuthan