Dropping in dialog retransmission with 183 Session Progress

[Laurent Schweizer]

Hello,

 

I have the following issue.

 

I send an INVITE and I get two  “183 Session Progress” , the first has no SDP, the second one contains a SDP .

 

The problem is that the second  “183 Session Progress” is detected as a retransmission and dropped by the SIP Stack

 

Any idea ?

 

Best regards

Laurent

 

23:02:38,843 INFO  [SipResourceAdaptor] Dropping in dialog retransmission. Response:

SIP/2.0 183 Session Progress^M

Call-ID: 43adf9c5109d67a8...@95.1.1.1^M

CSeq: 1 INVITE^M

From: "41215522000" <sip:41215...@95.1.1.1>;tag=1367182957630^M

To: "41763770377" <sip:41763...@212.161.147.221>;tag=517D8E6D-88F3646-0A13F641^M

Via: SIP/2.0/UDP 95.1.1.1:5060;branch=z9hG4bK-393934-ed0ce58552c9cc886f089dcb49fd781b^M

Contact: <sip:212.161.147.221:5060;transport=udp>^M

MIME-Version: 1.0^M

Supported: early-session^M

Allow: CANCEL,INFO,OPTIONS,BYE,PRACK,UPDATE^M

Content-Type: application/sdp^M

Content-Length: 309^M

^M

v=0^M

o=hiQ9200 1066120130328230237 1024852049 IN IP4 212.161.147.221^M

s=Phone Call via hiQ9200 SIPCA^M

c=IN IP4 212.161.147.221^M

t=0 0^M

m=audio 41542 RTP/AVP 8 18 101^M

a=rtpmap:8 PCMA/8000.

a=rtpmap:18 G729/8000.

a=fmtp:18 annexb=no.

a=rtpmap:101 telephone-event/8000.

a=fmtp:101 0-15.

a=sendrecv.

a=ptime:20.

 

 

 

 

U 212.161.147.221:5060 -> 95.1.1.1:5060

SIP/2.0 183 Session Progress.

Call-ID: 43adf9c5109d67a8...@95.1.1.1.

CSeq: 1 INVITE.

From: "41215522000" <sip:41215...@95.1.1.1>;tag=1367182957630.

To: "41763770377" <sip:41763...@212.161.147.221>;tag=517D8E6D-88F3646-0A13F641.

Via: SIP/2.0/UDP 95.1.1.1:5060;branch=z9hG4bK-393934-ed0ce58552c9cc886f089dcb49fd781b.

Contact: <sip:212.161.147.221:5060;transport=udp>.

Supported: early-session.

Allow: CANCEL,INFO,OPTIONS,BYE,PRACK,UPDATE.

Content-Length: 0.

.

 

 

U 212.161.147.221:5060 -> 95.1.1.1:5060

SIP/2.0 183 Session Progress.

Call-ID: 43adf9c5109d67a8...@95.1.1.1.

CSeq: 1 INVITE.

From: "41215522000" <sip:41215...@95.1.1.1>;tag=1367182957630.

To: "41763770377" <sip:41763...@212.161.147.221>;tag=517D8E6D-88F3646-0A13F641.

Via: SIP/2.0/UDP 95.1.1.1:5060;branch=z9hG4bK-393934-ed0ce58552c9cc886f089dcb49fd781b.

Contact: <sip:212.161.147.221:5060;transport=udp>.

MIME-Version: 1.0.

Supported: early-session.

Allow: CANCEL,INFO,OPTIONS,BYE,PRACK,UPDATE.

Content-Type: application/sdp.

Content-Length: 309.

.

v=0.

o=hiQ9200 1066120130328230237 1024852049 IN IP4 212.161.147.221.

s=Phone Call via hiQ9200 SIPCA.

c=IN IP4 212.161.147.221.

t=0 0.

m=audio 41542 RTP/AVP 8 18 101.

a=rtpmap:8 PCMA/8000.

a=rtpmap:18 G729/8000.

a=fmtp:18 annexb=no.

a=rtpmap:101 telephone-event/8000.

a=fmtp:101 0-15.

a=sendrecv.

a=ptime:20.

 

 

[Laurent Schweizer]

Regarding this issue, I found the following code :

 

public void checkRetransmissionForForking(SIPResponse response) {

        final int statusCode = response.getStatusCode();

        final String responseMethod = response.getCSeqHeader().getMethod();

        final long responseCSeqNumber = response.getCSeq().getSeqNumber();

        boolean isRetransmission = !responsesReceivedInForkingCase.add(statusCode + "/" + responseCSeqNumber + "/" + responseMethod);

        response.setRetransmission(isRetransmission);

        if (logger.isLoggingEnabled(LogWriter.TRACE_DEBUG)) {

            logger.logDebug(

                    "marking response as retransmission " + isRetransmission + " for dialog " + this);

        }

    }

 

 

I think  that :

                       boolean isRetransmission = !responsesReceivedInForkingCase.add(statusCode + "/" + responseCSeqNumber + "/" + responseMethod);

 

is not valid for provisional answer > 100 and < 200, as   non-provisional can be sent multiple time ( bellow in red )

 

Regards

 

Laurent

 

13.2.2.1 1xx Responses

   Zero, one or multiple provisional responses may arrive before one or

   more final responses are received.  Provisional responses for an

   INVITE request can create "early dialogs".  If a provisional response

   has a tag in the To field, and if the dialog ID of the response does

   not match an existing dialog, one is constructed using the procedures

   defined in Section 12.1.2.

 

 

13.3.1.1 Progress

   If the UAS is not able to answer the invitation immediately, it can

   choose to indicate some kind of progress to the UAC (for example, an

   indication that a phone is ringing).  This is accomplished with a

   provisional response between 101 and 199.  These provisional

   responses establish early dialogs and therefore follow the procedures

   of Section 12.1.1 in addition to those of Section 8.2.6.  A UAS MAY

   send as many provisional responses as it likes.  Each of these MUST

   indicate the same dialog ID.  However, these will not be delivered

   reliably.

   If the UAS desires an extended period of time to answer the INVITE,

   it will need to ask for an "extension" in order to prevent proxies

   from canceling the transaction.  A proxy has the option of canceling

   a transaction when there is a gap of 3 minutes between responses in a

   transaction.  To prevent cancellation, the UAS MUST send a non-100

   provisional response at every minute, to handle the possibility of

   lost provisional responses.

 

 

 

De : mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] De la part de Laurent Schweizer
Envoyé : dimanche 28 avril 2013 23:25
À : mobicent...@googlegroups.com
Objet : [mobicents-public] Dropping in dialog retransmission with 183 Session Progress

--
You received this message because you are subscribed to the Google Groups "mobicents-public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobicents-publ...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Laurent Schweizer]

Any idea ?

 

Laurent

 

De : mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] De la part de Laurent Schweizer
Envoyé : lundi 29 avril 2013 11:17
À : mobicent...@googlegroups.com
Objet : RE: [mobicents-public] Dropping in dialog retransmission with 183 Session Progress

[yulian_o]

Hello Laurent
First of all you are not correct about 183 multiple responses!

From RFC 3262 (page 8) which defines provisional response reliability :

.  A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response.  

So there is no any comparing of sdp content to know if its retransmission or not.
The only thing that is not implemented in stack is RSeq 

You have the following options to resolve this
1)Modify stack to handle RSeq changes ( this question already appears on mobicents forum , see here:
https://groups.google.com/forum/?fromgroups=#!searchin/mobicents-public/A$20response$20is$20a$20retransmission$20when|sort:relevance/mobicents-public/Sa1wi4d65x8/vSZMUnmLNFEJ
If you change the code change it for all 1xx responses not only ringing as posted in this thread.

2) Change the flow so first response will be 180 and second 183 ( as most providers does by the way ).

Best regards
Yulian Oifa

[Laurent Schweizer]

Hi Yulian,

 

In this case,  the INVITE don’t request the  Reliability of Provisional Responses, so no PRACK  message and no RSeq.

so in this case Dialog ID and Cseq are always them same .

so I will try to do the change in the stack

no not possible to change the order, it’s a big carrier and they use a Siemens high path  and no chance to change the order.

Best regards

Laurent 

 

De : mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] De la part de yulian_o
Envoyé : mercredi 15 mai 2013 14:12
À : mobicent...@googlegroups.com
Objet : Re: [mobicents-public] Dropping in dialog retransmission with 183 Session Progress

--