[SIPForum-discussion] Re-use of call-Id

[R.Jesske at telekom.de]

Hi,
RFC 3261:
21.5.4 503 Service Unavailable


   ... A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   attempt to forward the request to an alternate server.  It SHOULD NOT
   forward any other requests to that server for the duration specified
   in the Retry-After header field, if present. ...

In the case no retry after header is within 503 there is no time limit given for the alternate destination.

The question is what will happen if you get an additional 503 from the alternative destination?
Because then there should start specific restrictions to avoid generating too many SIP messages (avoiding loops) by the UAC.

Best Regards

Roland


Von: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] Im Auftrag von Leviatan, Chava
Gesendet: Mittwoch, 4. Januar 2017 17:34
An: discussion at sipforum.org
Betreff: [SIPForum-discussion] Re-use of call-Id

Hi ,

I faced the following scenario:


1.      UAC sends INVITE

2.      UAC receives 100 Trying

3.      UAC Receives 503

4.      UAC sends ACK

Immediately  after that ,  the  UAC sends the same INVITE , i.e. same call-id , same from tag ,  same CSEQ . It is sent from a different IP , and to a different IP . I.e. if 1-4 were sent from IP A to IP B , then repeated 1 -4 is sent from IP C to IP D .

The whole episode ( INVITE -> ACK ) is less than 300 millis , i.e. less than T1

Is that standard ?

When I look at the INVITE transaction diagram on 17.1.1.2 , the client should get into terminate state after Timer D fires .
On the other hand , this INVITE should not  be re-transmitted ( as part of the transaction ) as it received 100 Trying ( and 503 )

Appreciate any views you have on that

Thanks ,
Chava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20170110/336ea6aa/attachment-0002.html>