Martin,
You left out a few details that are significant:
- Does the AS act as a B2BUA for the call?
- If so, is it in the media path too (terminating and reoriginating
the media), or only in the signaling path?
If the AS is in the media path then of course it can originate its own
media and send it in that path. But, while it can relay media without
actual codec support, it won't be able to originate its own media if it
doesn't support the codec selected by UE B.
The AS MAY send another 180 with a different answer to the offer that is
compatible with its own supported codecs. But to do so legally, it must
select a different to-tag in that response. That makes it appear to UE A
that the call was forked (which in fact it was).
The latter approach should cover all of your cases. It does however
depend on UE A properly handling the forking case and making a suitable
decision about which media to render.
Paul
[EMAIL PROTECTED] wrote:
Hello all,
I am thinking about one problem, consider following message flow:
1. UE A sends SIP INVITE message with SDP offer to EU B
2. On originating call leg there is application server announced about the call.
3. 180 Ringing message with SDP answer is sent from UE B to UE A (AS is
announced that the call is in progress)
4. Time frame allocated to establish the call passed at AS and the message
needs to be played ...
Can now the AS make use of negotiated media paths and play some "called party not
available" message without sending 200 OK message first?
My assumption here is that media paths are negoiated (UE A claims sendrecv audio channel
so it must be prepare to receive media) so AS "can" send this message.
Consider also little complication, AS is not able to play media in a codec
claimed in the answer. Can AS send another 180 ringing message where the
appropriate codec will be issued?
I will appreciate any clarification on this issues.
br, Martin
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
