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@freeswitch.org and file a bounty for a non-standard feature.

On Wed, Oct 27, 2010 at 6:15 AM, Irina Ivanova <i.ivanova@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.syst...

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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org