Tim -
As others have mentioned, newer versions of SDP don't permit FQDNs.
However, as you point out, there are other ways for the SDP to be
syntactically correct and yet unusable, either initially or later.
I have posted on this before. There are real problems in deciding on
recovery strategies, and in coordinating them between the endpoints.
As you suggest, a reINVITE is one possible recovery action, but it
is currently no obvious way to encode a reinvite to say "I don't want
to change my SDP, but I want you to fix a problem with yours."
Perhaps this is a case for using a Reason header in an INVITE.
Paul
Tim Johnson wrote:
>
> I have a question about what, if any, SIP behaviour there should be
> if a UA receives SDP with a connection address expressed as a
> domain name and which cannot be resolved. In this case at least one,
> and possibly all, media streams cannot be sent. This is also similar
> to an ARP failure on a LAN but probably much more likely to occur.
> There is also a similarity to receiving an ICMP unreachable
> indication for a media stream in progress. In all cases the media
> cannot be sent yet the signalling channel, especially in the case of
> 3PCC, may be unaffected.
>
> If the SDP was in an INVITE, the response could indicate a DNS
> resolution failure (although no response codes are defined which
> cover this specific case). But the SDP could also be in either a 2xx
> response or in an ACK. In these cases, a re-INVITE could be sent
> following the completion of the INVITE transaction which
> contained the unresolved name. Alternatively, a BYE could be sent
> to terminate the session. Finally, the session could be unaffected and
> corrective actions left to the user which notices a lack of media.
>
> Only the BYE seems deterministic since a response to a re-INVITE
> is likely to contain the same SDP as caused the resolution failure.
> However it would appear to be too drastic if there were other media
> streams in the session which did resolve (i.e. the c= which did not
> resolve was within one of several media descriptions and not at the
> session level). What is the accepted solution here?
>
> Thanks,
> Tim
>
> _______________________________________________
> 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
