Paul Kyzivat wrote:
[snip]
Consider the following:
An INVITE that contains both sdp and a body part referenced by a Geoloc
header. Those two parts aren't related to one another, so they go into a
multipart/mixed in the INVITE. The reference is from the headers of the
sip message to one of the body parts within the multipart/mixed.
Something similar could occur in a response to an INVITE as well, though
probably not with geoloc. For instance there could be an Alert-Info
header referencing a body part containing a picture of the callee.
Now suppose a REFER causes an INVITE that has such a response. And the
entire response is returned in sipfrag in a NOTIFY to the referror. So
then you have: A REFER with a body of type sipfrag. The body in turn
contains a body of type multipart/mixed. The multipart/mixed contains an
SDP part and an image part. The sip headers in the sipfrag reference the
image part in the contained multipart/mixed.
Now *probably* the image part in the response to the invite would have
handling=optional. Or it could have had handling=required if the callee
felt strongly about presenting its image. I don't know what should
happen to the INVITE if the image body part wasn't understood. Nor do I
understand what should happen to the NOTIFY if the recipient doesn't
understand the image.
On this last part, message/sipfrag is not a multipart so I don't think
the rules in the body-handling draft really applies to how the referrer
processes this NOTIFY. The sipfrag may include a body which may be a
multipart but the entire sipfrag will be transported as an opaque
non-multipart in the NOTIFY. So I would tend to think that this draft is
irrelevant as far as interpreting sipfrags is concerned.
Anders
_______________________________________________
Sip mailing list https://www.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
