> From: Pranab Bohra [[email protected]]
>
> Is it mandatory to use the same method ( UPDATE or re-INVITE ) while
> an UA is handling the glare condition ?
No. The remote UA has rejected the request and remembers nothing of
it.
> 1. Let's say, UA1 and UA2 have set up an early dialog.
> 2. UA2 sends ACK which would result in a confirmed dialog.
> 3. UA1 initiates the UPDATE transaction to modify the session because it has
> not seen the ACK to the initial INVITE yet. (because rfc 3311 recommends that
> UPDATE should be used for early dialogs and re-INVITE in case of confirmed
> dialogs)
> 4. UA2 has initiated re-INTIVE at the same time.
> 5. UA2 responds back to the UPDATE that UA1 had sent in step 3 with 491.
> 6. UA1 terminates the UPDATE transaction and tries to modify the session
> again by sending another SDP Offer. (as per Sec. 14.2 of rfc 3261) But now
> that it's a confirmed dialog, UA1 sends re-INVITE rather than UPDATE.
>
> UA1 UA2
> | early dialog |
> |<============>|
> | ACK |
> |<---------------------|
> | UPDATE |
> |<---------------------|
> | re-INVITE |
> |<---------------------|
> | 491 |
> |<---------------------|
> | re-INVITE |
> |--------------------->|
Beware that you have diagrammed the UPDATE in the wrong direction.
Also, the diagram shows the ACK arriving at UA1 before the UPDATE is
sent. You want a diagram like the one in RFC 5407 section 3.1.2:
[mono-space:]
State Alice Bob State
| |
| INVITE F1 |
|----------------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------------|
Ear | | Ear
|CANCEL F3 200(INVITE) F4|
|------------ -------------|
| \ / | Mora
| X |
| / \ |
|<----------- ------------>| *race*
Mora | |
| ACK F6 200(CANCEL) F5|
|------------ -------------|
Est | \ / |
| X |
| / \ |
|<----------- ------------>|
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
