14 Jun
2006
14 Jun
'06
2:46 p.m.
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(a)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(a)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(a)thursday.com
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
14 Jun
14 Jun
4:24 p.m.
New subject: [Serusers] Content-Type: multipart/mixed; boundary=uniqueBoundary problems?
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(a)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(a)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(a)thursday.com
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6740
days inactive
6740
days old
1 comments
2 participants
participants (2)
-
Evan Borgström -
Jiri Kuthan