Your scenarios below are confusing and incomplete. Its hard to
understand the point you are trying to make. More inline...
Srinivas wrote:
> Hi all,
> Consider the following scenarios.
>
> 1.
> C->S: INVITE (for speechrecog)
> S->C: 200 OK
> C->S: ACK
>
> Now the SIP session is established b/w UAC and UAS. speechrecog
> resource is active on the established sip session
>
> C->S: INVITE (re-INVITE for adding speechsynth resource)
> S->C: 200 OK
> Offer/Answer fail for the new resource, TTS (speechsynth).
What was going on here? Was this adding another media line, or replacing
the existing media line? How did it fail? (By refusing the new media
line with port=0, or what?)
Why is there no ACK? Did you just not show it? Or is it not present?
> 2.
> C->S: INVITE (for speechrecog)
> S->C: 200 OK
> C->S: ACK
>
> Now the SIP session is established b/w UAC and UAS. speechrecog
> resource is active on the established sip session.
>
> C->S: INVITE (re-INVITE for adding speechsynth resource)
> S->C: 200 OK
> Offer/Answer fail for the for the existing ASR(speechrecog) resource
> also.
This seems exactly the same as 1. Why are you showing it again? Is all
this additional signaling in the same session as 1, or is this intended
to be a different scenario?
> 3.
> C->S: INVITE (for speechrecog)
> S->C: 200 OK
> C->S: ACK
>
> Now the SIP session is established b/w UAC and UAS. speechrecog
> resource is active
>
> C->S: INVITE (re-INVITE for adding speechsynth resource)
> S->C: 200 OK
> C->S: ACK
>
> Now both speechrecog and speechsynth are active on the sip session
So does this mean that you have two media streams in the session? Or what?
> C->S: INVITE (re-INVITE for removing speechsynth resource)
> S->C: 486 BUSY HERE
It seems very unusual to get a 486 on a reinvite. But it is still just a
reinvite, so its failure doesn't impact the existing session.
> What should be the behaviour of UAC in the above scenarios?
First you need to send an ACK for this. Then you *may* continue with
both resources in the session. Or you can try again. Or you can send a
BYE if you are sufficiently upset with the situation.
If you want more help, please send more complete call flows, with the
actual (or representative) headers and SDP.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
