Re: [asterisk-users] Is this SDP payload Asterisk created valid?
On 27/09/13 14:28, Gareth Blades wrote:
On 27/09/13 14:15, Gareth Blades wrote:
Can anyone with a bit more knowledge about the SDP standard tell me
if what asterisk is doing is correct?
Or if it must be a bug with our customers equipment?
Reading RFC2327 it cais the c= line 'must' be present in all updates
while 'm=' media lines are optional.
I am therefore inclined to believe that Asterisk is working correctly
and there is a bug in the customers SIP equipment.
But thats just my personal interpretation from briefly reading the
standard.
Well looking at RFC4566 section 5 :-
Some lines in each description are REQUIRED and some are OPTIONAL,
but all MUST appear in exactly the order given here (the fixed order
greatly enhances error detection and allows for a simple parser).
OPTIONAL items are marked with a "*".
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
So if I am reading that correctly the m= line is required only if we
include a media description entry. It basically sais its required if we
decide to include it (yes I know that doesnt make sense). What I presume
this means is that if a media description is included such as there
being a 'a=' line then the 'm=' line then becomes required.
So it still sounds like Asterisk is behaving correctly.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is this SDP payload Asterisk created valid?
On 27/09/13 14:36, Joshua Colp wrote: Gareth Blades wrote: We have an issue with a customer where when calls are sent to one of their offices as soon as the call is answered the call fails. We are performing remote bridging and switching the audio from the server which initiated the call to our switch which is on the same network. After the call is answered we switch the audio which is accepted fine but we then send the following packet and get a SIP/488 response from the far end. This packet seems to be updating the version for the o= session id which is fair enough. Its sending the c= connection data but not the m=audio line which appears to be what the remote end is complaining about. Can anyone with a bit more knowledge about the SDP standard tell me if what asterisk is doing is correct? Or if it must be a bug with our customers equipment? The SDP you posted should be fine BUT my question becomes... have you modified chan_sip at all? I don't think it should be possible for it to not put any media lines in... Cheers, No we havent made any changes to chan_sip. The servers were a fresh install a short while ago straight to 11.2-cert1 as we wanted a later kernel version to make use of the new timing source it provides. We then upgraded to cert2 after it was released. The only thing we have changed is the setting of a DYNAMIC_FEATURES variable which was stopping remote bridging from being performed which is probably what has highlighted this fault. Thanks Gareth -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is this SDP payload Asterisk created valid?
Gareth Blades wrote: We have an issue with a customer where when calls are sent to one of their offices as soon as the call is answered the call fails. We are performing remote bridging and switching the audio from the server which initiated the call to our switch which is on the same network. After the call is answered we switch the audio which is accepted fine but we then send the following packet and get a SIP/488 response from the far end. This packet seems to be updating the version for the o= session id which is fair enough. Its sending the c= connection data but not the m=audio line which appears to be what the remote end is complaining about. Can anyone with a bit more knowledge about the SDP standard tell me if what asterisk is doing is correct? Or if it must be a bug with our customers equipment? The SDP you posted should be fine BUT my question becomes... have you modified chan_sip at all? I don't think it should be possible for it to not put any media lines in... Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is this SDP payload Asterisk created valid?
On 27/09/13 14:15, Gareth Blades wrote: Can anyone with a bit more knowledge about the SDP standard tell me if what asterisk is doing is correct? Or if it must be a bug with our customers equipment? Reading RFC2327 it cais the c= line 'must' be present in all updates while 'm=' media lines are optional. I am therefore inclined to believe that Asterisk is working correctly and there is a bug in the customers SIP equipment. But thats just my personal interpretation from briefly reading the standard. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Is this SDP payload Asterisk created valid?
We have an issue with a customer where when calls are sent to one of their offices as soon as the call is answered the call fails. We are performing remote bridging and switching the audio from the server which initiated the call to our switch which is on the same network. After the call is answered we switch the audio which is accepted fine but we then send the following packet and get a SIP/488 response from the far end. This packet seems to be updating the version for the o= session id which is fair enough. Its sending the c= connection data but not the m=audio line which appears to be what the remote end is complaining about. Can anyone with a bit more knowledge about the SDP standard tell me if what asterisk is doing is correct? Or if it must be a bug with our customers equipment? Thanks Gareth U 2013/09/27 11:04:55.352854 88.x.x.25:5060 -> 213.x.x.24:5060 INVITE sip:0844xx@146.x.x.10:54900 SIP/2.0. Via: SIP/2.0/UDP 88.x.x.25:5060;branch=z9hG4bK62215713. Route:. Max-Forwards: 70. From:;tag=as691af817. To:;tag=ee7a6c7cad57f096i1. Contact:. Call-ID: 2eeb643d086234de59a1fd4e78170d3f@88.x.x.25:5060. CSeq: 104 INVITE. User-Agent: Asterisk PBX 11.2-cert2. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH. Supported: replaces, timer. Content-Type: application/sdp. Content-Length: 110. . v=0. o=root 716216031 716216033 IN IP4 88.x.x.35. s=Asterisk PBX 11.2-cert2. c=IN IP4 88.x.x.35. t=0 0. # U 2013/09/27 11:04:55.365458 213.x.x.24:5060 -> 88.x.x.25:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 88.x.x.25:5060;branch=z9hG4bK62215713;rport=5060. From:;tag=as691af817. To:;tag=ee7a6c7cad57f096i1. Call-ID: 2eeb643d086234de59a1fd4e78170d3f@88.x.x.25:5060. CSeq: 104 INVITE. Server: OpenSIPS (1.5.3-notls (x86_64/linux)). Content-Length: 0. . # U 2013/09/27 11:04:55.431674 213.x.x.24:5060 -> 88.x.x.25:5060 SIP/2.0 488 Not Acceptable Here. To:;tag=ee7a6c7cad57f096i1. From:;tag=as691af817. Call-ID: 2eeb643d086234de59a1fd4e78170d3f@88.x.x.25:5060. CSeq: 104 INVITE. Via: SIP/2.0/UDP 88.x.x.25:5060;rport=5060;received=88.x.x.25;branch=z9hG4bK62215713. Record-Route:. Contact: "freespeech". Warning: 304 spa "Media type not available". Server: Cisco/SPA303-7.5.4. Content-Length: 0. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
