Hi Mike,
I have a quote here from "draft-ietf-mmusic-sdp-offer-answer-02.txt"
which may be of help:
The offer/answer exchange is atomic; if
the answer is rejected, the session reverts to the state prior to the
offer (which may be absence of a session).
To me it seems that if the SDP "answer" in the ACK is NOT a codec
contained in the "offer" then can we not consider this to be a rejection?
If so, then you should revert back to the state you were in before the
INVITE was sent. If that means that a call wasn't up, then the call
should be terminated (I would send a BYE to make sure it is).
Regards,
Attila
<http://www.vegastream.com>
VegaStream : A World of difference for your Integrated Communications
> -----Original Message-----
> From: Feldman, Michael [mailto:[EMAIL PROTECTED]]
> Sent: 23 May 2002 15:14
> To: 'Ranjit Avasarala'; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] reinvite question
>
>
> If you want to change the codec for instance...
> (mind you I do not know why the user2 would want to reject
> the re-invite
> because user1 should be using a codec offered in the 200ok...)
>
> mike
>
> -----Original Message-----
> From: Ranjit Avasarala [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 22, 2002 10:55 PM
> To: Feldman, Michael; [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] reinvite question
>
>
> Hi
> re-invite is sent when u want to change the session
> parameters, but I
> don't see any such thing here. so why do u want to use re-invite?
>
> Ranjit
> ----- Original Message -----
> From: "Feldman, Michael" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 22, 2002 11:07 PM
> Subject: [Sip-implementors] reinvite question
>
>
> > when you have a re-invite, how does the far end reject the
> changes in
> > the
> > following case...
> > (mind you I am not sure when this would happen)
> >
> >
> > Call in progress...
> > user1
> > user2
> > Invite (no SDP information) -->
> > <-- 200 OK (with SDP information)
> > ACK (with SDP information) -->
> >
> > user 2 does not like the information given in the ACK by user1,
> > a bye does not make sense since we do not want to terminate
> the call.
> >
> >
> >
> > thanks,
> > mike
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
