Hi Brett,
For (b), thanks for the pointer to RFC 5359, it answers our queries.
I hope the figure for (a) is OK this time. The point I was making is, the
Softswitch has to ensure that the "To" tag of message 11 (18x with SDP_answer2
to Proxy A) is different from that of message 5 (180 Ringing with SDP_answer1
to Proxy A).
2 options exist for this for the softswitch) - I'd prefer (b) strongly:
(a) It can proxy the 'new' To Tag that it received from Proxy C (because the
earlier To tag was generated by the softswitch itself)
(OR)
(b) Generate a new To tag for message 11.
The assumption in this scenario is that the A-side does not support reliable
18x responses. If this was supported, then 18x (message 10) can be interworked
to an UPDATE by the softswitch.
User A Proxy A Softswitch ISDN User B Proxy C User C
| | | |
| |
|---------------->| | |
| |
| 1. INVITE(SDP_offer1) | |
| |
| |----------------->| |
| |
| |2. INVITE (SDP_offer1) | |
|
| | |----------------->| |
|
| | | 3. SETUP | |
|
| | |<-----------------| |
|
| | | 4. Alerting | |
|
| |<----------------- | |
| |
| |5. 180 Ringing (SDP_answer1 ) | |
|
|<----------------| | |
| |
|6. 180 Ringing (SDP_answer1 ) | | |
|
| | | |
| |
| <WAIT_ANSWER_TIMER EXPIRES> | | |
| <A 181/183 may be sent by Softswitch to indicate
CFNR> |
| | | |
| |
| | |---------------------------------->|
|
| | | 7. INVITE (SDP_offer1) |
|
| | | |
|---------------->|
| | | |
|8. INVITE(SDP_offer1)
| | | |
|<--------------- |
| | | |
|9. 18x (SDP_answer2)
| | |<----------------------------------|
|
| | | 10. 18x (SDP_answer2) |
|
| |<----------------- | |
| |
| |11. 18x (SDP_answer2) | |
|
|<----------------| | |
| |
|12. 18x (SDP_answer2) | |
| |
| | | |
| |
Regards,
Swami.
-----Original Message-----
From: Brett Tate [mailto:[email protected]]
Sent: Friday, April 18, 2014 9:49 PM
To: Swaminathan S (WT01 - Global Media & Telecom);
[email protected]
Subject: RE: [Sip-implementors] Reg. CFNR
Hi,
Your pictures were not received.
I assume that your CFNR examples are similar to RFC 5359's "Call Forwarding -
No Answer" or "Call Forwarding Unconditional".
Within both of your cases, the offer/answer rules apply. However be aware that
the offer/answer rules don't work very well if devices (or their deployed
configuration) don't support forking proxies or RFC 3262/3311.
Concerning case a), your understanding sounds correct if the softswitch
supplied an (answer or preliminary answer) SDP within 18x and it actually needs
to change the SDP before receiving ACK.
Concerning case b), I'll assume that the flow is similar to RFC 5359's "Call
Forwarding - No Answer". As shown within the example, the proxy uses a dialog
that it creates if generating 18x (instead of proxying 18x) during call setup.
See 181 response within the example.
> -----Original Message-----
> From: [email protected] [mailto:sip-
> [email protected]] On Behalf Of
> [email protected]
> Sent: Friday, April 18, 2014 6:16 AM
> To: [email protected]
> Subject: [Sip-implementors] Reg. CFNR
>
> Hi,
>
> We would like to know what would happen in the following cases
> involving CFNR:
>
>
> (a) SIP User A calls a ISDN User B connected to a Class 5
> softswitch. User B has CFNR to a SIP user C. The scenario is
> illustrated below. Upon reception of message 10 (18x) with
> SDP_answer2, we assume that the softswitch shall send the 18x (message
> 11) with a different "To" tag, as compared to what was sent in message 5.
> Otherwise, we don't see a way of transporting the "new" SDP answer
> before the completion of INVITE transaction in the case of unreliable
> 18x responses. Is our understanding correct?
>
> Note: In the case of reliable 18x responses, message 10 can be
> interworked by the softswitch to an UPDATE message.
>
>
>
> [cid:[email protected]]
>
>
> (b) SIP User A calls SIP User B. SIP endpoint B has CFNR active to
> another SIP User C.
>
> The scenario is illustrated below. Our understanding is, Proxy B sends
> the 180 Ringing (message 12) with a different "To" tag, as compared to
> the one in message 5, if reliable 18x response is not supported. Is
> this correct?
>
>
>
> [cid:[email protected]]
--
This email is intended solely for the person or entity to which it is addressed
and may contain confidential and/or privileged information. If you are not the
intended recipient and have received this email in error, please notify
BroadSoft, Inc. immediately by replying to this message, and destroy all copies
of this message, along with any attachment, prior to reading, distributing or
copying it.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
