2012/7/27 Worley, Dale R (Dale) :
> On Fri, 2012-07-27 at 10:09 -0400, Roman Shpount wrote:
>> The more I think about it, [...] The continuation of this discussion
>> should probably take in sipcore.
>
> Why don't you write an Internet-Draft containing your proposed
> improvements, and then submit
On Fri, 2012-07-27 at 10:09 -0400, Roman Shpount wrote:
> The more I think about it, [...] The continuation of this discussion
> should probably take in sipcore.
Why don't you write an Internet-Draft containing your proposed
improvements, and then submit it for discussion in Sipcore?
Dale
_
Inaki,
You have misunderstood what I have said: The flow token is generated and
added to the route header by the edge proxy. The flow token that edge proxy
should put in the route header should be constructed in such a way that can
be used to locate the registration from this particular user agent
> I hope this holds good, even if there is change
> of offer/answer in between (18X reliable & 200 ok).
> My doubt is that, the UAS can still send the same
> session description in 200 ok (of Invite) as in 18x
> (reliable). This session description could be
> different from what was exchanged p
Hi,
Ideally both should have same answer. If different then UAC should
consider first offer received as answer.
Refer 3261 :
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 INVIT
Hi Roman, sorry for the late response:
2012/6/18 Roman Shpount :
> You can work around the issue you mention by putting the public GRUU in the
> route header instead of flow token. For all the subsequent requests proxy
> will look up if the flow exists for this GRUU and send the request over this
> Whether below mentioned scenarios correct from
> Offer/Answer model point of view ?
>
> 1. INVITE/18x (Reliable) for Offer/Answer1.
>
> 200 OK (INVITE)/ACK for Offer/Answer2.
No.
> 2. INVITE/18x (Reliable) for Offer/Answer1.
>
> PRACK/200 OK (PRACK) for Offer/Answer2.
Yes.
> 2
I hope this holds good, even if there is change of offer/answer in between (18X
reliable & 200 ok). My doubt is that, the UAS can still send the same session
description in 200 ok (of Invite) as in 18x (reliable).
This session description could be different from what was exchanged previously
usi
Hi Kumar,
Yes you are correct. The UAS can not initiate subsequent offer if it has
already sent or received answer of offer in initial transaction.
Reference Refer RFC 3261:
Once the UAS has sent or received an answer to the initial
offer, it MUST NOT generate subsequent off
Hi *,
Whether below mentioned scenarios correct from Offer/Answer model point of view
?
1. INVITE/18x (Reliable) for Offer/Answer1.
200 OK (INVITE)/ACK for Offer/Answer2.
2. INVITE/18x (Reliable) for Offer/Answer1.
PRACK/200 OK (PRACK) for Offer/Answer2.
200 OK (INVITE)/ACK for O
10 matches
Mail list logo
