[Freeswitch-dev] Handling of multiple 183 responses with different SDP

Thu Oct 28 07:02:51 PDT 2010

Thank you for the response and for the correct link to RFC. It is 
exactly what was missing and what we couldn't manage to find ourselves 
while trying to clear up the situation with our provider. If we won't be 
able to resolve this issue with them we'll consider filing the bounty 
for this feature.

Anthony Minessale wrote:
> Mentioning that it works with asterisk is essentially admitting that its wrong.
>
> Trying to use RFC as an excuse to make me change something annoys me
> so let me have my turn now:
>
> RFC 3261  section 13.2.1 bullet 2:
>
> "If the initial offer is in an INVITE, the answer MUST be in a reliable
> non-failure message from UAS back to UAC which is correlated to that
> INVITE.  For this specification, that is only the final 2xx response to
> that INVITE.  That same exact answer MAY also be placed in any
> provisional responses sent prior to the answer.  The UAC MUST treat the
> first session description it receives as the answer, and MUST ignore any
> session descriptions in subsequent responses to the initial INVITE."
>
> ADOPTED RFC vs expired draft.
>
> So that's the end I guess unless you want to email
> consulting at freeswitch.org and file a bounty for a non-standard
> feature.
>
>
> On Wed, Oct 27, 2010 at 6:15 AM, Irina Ivanova <i.ivanova at mastervoice.it> wrote:
>   
>> Hi! We are getting the same problem as described in the jira ticket with
>> key FS-715:
>> http://jira.freeswitch.org/browse/FS-715?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
>>
>> Our provider is also sending us more than one 183 Session progress
>> response, each of them with SDP where destination IP address is the same
>> but the UDP ports are different.
>>
>> If is needed I can provide the pcap file where you can see that after
>> receiving of second 183 Session progress response (with updated SDP)
>> Freeswitch continues to listen on an old port. As a consequence, no
>> audio can be heard.
>>
>> Our provider assures us that sending of more than one 183 Session
>> progress responses is completely standard behavior that does not violate
>> SIP RFC 3261 and is handled correctly by any ATA VoIP.
>> We verified the Asterisk behavior in this case, and can say that it
>> handles receiving of multiple 183 Session progress responses without any
>> problems and changes the UDP port each time it gets changed in session
>> description inside of 183 response.
>>
>> Our provider gave us a reference to SIP RFC 3261:
>>
>> 13 Initiating a Session
>> 13.1 Overview
>> "Before sending a final response, the UAS can also send provisional
>> responses (1xx) to advise the UAC of progress in contacting the called user.
>> After possibly receiving one or more provisional responses, the UAC will
>> get one or more 2xx responses or one non-2xx final response."
>>
>> "one or more provisional responses" was underlined by our provider and
>> in addition to this was said that there is no any place in RFC from
>> which you can conclude that you can not send more than one SIP 183
>> Session Progress response.
>>
>> We also found a document regarding 183 response:
>> http://tools.ietf.org/html/draft-ietf-sip-183-00
>>
>> Here are some references to the parts talking about temporary media and
>> session description change:
>>
>> 4.2. Change of Temporary Media
>>
>>   After a temporary media stream has been established, its parameters
>>   can be changed by sending further provisional responses that also
>>   contain session descriptions. Upon receipt of such a response, the
>>   client MUST immediately cease transmission of media relating to the
>>   old temporary stream. As before, the new temporary media stream is
>>   established after acknowledgement of the provisional response.
>>
>>   Provisional responses which contain no session description SHOULD NOT
>>   have an effect on any currently established temporary media stream.
>>
>>
>> 5.11.7 Caller Receives 183 Response
>>
>>   When the calling UA receives a 183 response that contains a session
>>   description and an indication that the session description is for
>>   early media, it SHALL setup the associated media session and present
>>   any media received from the called UA to the user.
>>
>>
>> Again nothing is said about multiple 183 responses specifically, only
>> about multiple provisional responses in general.
>> So, is there anything that can be done to resolve this issue?
>> Thanx,
>> Irina
>>
>> --
>> ================================================================
>>
>> Distinti saluti
>> --
>>
>> Irina Ivanova
>> Settore Sviluppo MasterVoice
>>
>> tel: +39 0522 1846007
>> fax: +39 0522 331673
>> mob: +39 334 6449290
>> e-mail: i.ivanova at mastervoice.it
>> web: www.mastertraining.it - www.registroelettronico.com
>>
>> Master Training S.r.l.
>> Sede Legale: via Timolini, 18 - Correggio (RE) - Italy
>> Sede Operativa: via Sani, 15 - Reggio Emilia - Italy
>> Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy
>>
>> ================================================================
>> Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili.
>> This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.
>>
>>
>> _______________________________________________
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>     
>
>
>
>   