inline
NC Reddy wrote:
> Hi,
> In this problem context, i found another issue, how routing b2bua proxy
> will decide when to suppress offer/answer message(s) to other hop.
>
> What's the condition for the AS (application server) to know offer/answer is
> done between A and B
> UserA <------->AS(B2BUA)<---->UserB
> Where AS is pure signaling routing proxy, it won't involved in any media
> negotiations between A and B.
>
> The actual problem scenario as follows:
>
> User(A)<------->AS (B2BUA)<--------->AnnouncementServer(AnnS) UserB
> Scenario:
> 1. User A initiate a call to UserB along with feature code
> 2. AS sends INVITE to AnnServer
> 3. AnnServer sends 200 OK with Ans-1
> 4. AS sends 183 with Ans-1 to User-A (Early Dialog w.r.t to UserA
> client)
> 5. AS sends INVITE to UserB with offer-A1.
> 6. User B responded with 183 with Ans-B1
>
> Now the questions are:
> 7. AS sends the Ans-B1 as "update offer" to userA in "UPDATE" message
> (since it early dialog AS can't use re-INVITE)
As you have explained the flow, the UPDATE new offer is also illegal.
If you want to do that then you will have to use reliable provisionals.
So User(A) will have to indicate support for 100rel, then the 183 with
the first answer from AS to User(A) will have to be marked as reliable,
User(A) will have to send PRACK, and AS must send 200 to PRACK. *Then*
AS may send an UPDATE with another offer.
> 8. UserA client responded with Ans-B2.
>
> 9. How AS can figure out that the Ans-B2 given by userA client needs to pass
> to other hop (i.e towards to userB) in PRACK or supress it?.
> 10. What's the trigger for AS (i.e Pure routing B2BUA proxy) decide when to
> stop offer and answer exchanges with peer UAC/UAS?
I think your problem is that you are thinking of the AS as a proxy, but
asking it to do things that only a B2BUA can do.
Stop thinking of it as a proxy. Think of it as three UAs - one facing
User(A), one facing AnnS, and one facing User(B). Each of these UAs is
establishing its own dialog and carrying out its own O/A exchange. The
B2BUA logic in this then coordinates their actions. So information from
the answer received from AnnS may be used to *generate* an answer to
User(A), and the answer from User(B) may be used to *generate* a new
offer to User(A). But the B2BUA has to put some thought into it and do
some transformations in order to generate appropriate messages for
User(A). It is not as simple as proxying the messages on to User(A).
You are discovering the cruel fact that what you are trying to do is not
as trivial as it might have first seemed. It would be easier on the
B2BUA to simply treat this as two dialogs back to User(A). Then more of
the bookkeeping is shifted to User(A). But if the calling UAs can't
handle that then you may need to do the hard work.
Let me once again ask that you read the offeranswer draft that I
referenced earlier. You are traveling ground that has been traveled many
times before.
> 11. What's could be the ideal behavior of AS for user A point of view, when
> call connected to UserB , does user A should get 180 ringing or AS can
> suppress it?. If suppress UserA never hear the ring tone,
This is your choice, depending on what you want the user experience to
be. But it also depends on behavior of User(A) that isn't very
standardized. Often a UA, once having started playing out in-band media,
will not generate local ringback upon receipt of a 180.
Paul
> Regards
> Channa
>
>
> On Thu, May 8, 2008 at 3:02 PM, NC Reddy <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>> In this problem context, i found another issue, how routing proxy will
>> decide when to suppress offer/answer message to other hop
>>
>> User(A)<------->AS (B2BUA)<--------->AnnouncementServer(AnnS) UserB
>> Scenario:
>> 1. User A initiate a call to UserB with along feature code
>> 2. AS sends INVITE to AnnServer
>> 3. AnnServer sends 200 OK with Ans-1
>> 4. AS sends 183 with Ans-1 to User-A (Early Dialog w.r.t to UserA
>> client)
>> 5. AS sends INVITE to UserB with offer-A1.
>> 6. User B responded with 183 with Ans-B1
>>
>> Now the questions are:
>> 7. AS sends the Ans-B1 as "update offer" to userA in "UPDATE" message
>> (since it early dialog AS can't use re-INVITE)
>> 8. UserA client responded with Ans-B2.
>>
>> 9. How AS can figure out that the Ans-B2 given by userA client needs to
>> pass to other hop (i.e towards to userB) in PRACK or supress it?.
>> 10. What's the trigger for AS (i.e Pure routing B2BUA proxy) decide when to
>> stop offer and answer exchanges with peer UAC/UAS?
>>
>> 11. What's could be the ideal behavior of AS for user A point of view, when
>> call connected to UserB , does user A should get 180 ringing or AS can
>> suppress it?. If suppress UserA never hear the ring tone,
>>
>> I attached the call flow doc in the bmp file.
>>
>> Regards
>> Channa
>>
>>
>>
>>
>> On Thu, May 8, 2008 at 12:05 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]>
>> wrote:
>>
>>> El Thursday 08 May 2008 17:28:17 Paul Kyzivat escribió:
>>>> It is valid as long as different to-tags are used.
>>>>
>>>> But often people try to do this exact same scenario, but send the
>>>> responses, with changed SDP, using the *same* to-tag. That is wrong.
>>> Nice to know.
>>>
>>>
>>>> This is all explained in the o/a draft. It exists because questions like
>>>> this come up so often.
>>> draft-ietf-sipping-sip-offeranswer-08:
>>>
>>> "The description of the offer/answer
>>> model in SIP is dispersed across multiple RFCs. This document
>>> summarizes all the current usages of the offer/answer model in SIP
>>> communication."
>>>
>>> That's great :)
>>>
>>> --
>>> Iñaki Baz Castillo
>>> [EMAIL PROTECTED]
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
