Thanks Paul for your great suggestions. Since, I don't want to add traffic
to network, so I don't want to use a separate set of SIP MESSAGE
request/response. Based on our requirements, I find your suggestion of
Content-ID header field option being really suitable. I am putting the
request/response snippet below as per my understanding from your suggestion
and various RFCs, please let me know if that looks good.
For example -
*Server to Client :*
MESSAGE <server-uri>
:
Content-Type: application/chat-info+xml
Content-Length: ...
<?xml version="1.0"?>
<chat-info>
:
</chat-info>
*Client to Server:*
SIP/2.0 200 OK
:
Call-Info:<cid:cn35t8jf02@example.com>; purpose=info
Content-Type: application/chat-info+xml
Content-Length: ...
content-ID:<cn35t8j...@example.com>
<?xml version="1.0"?>
<chat-info>
:
</chat-info>
Regards
Abhishek
On Sat, Apr 13, 2019 at 4:36 PM Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
> On 4/13/19 4:43 PM, abhishek jain wrote:
> > Thanks Paul for your quick response on a Saturday. I really appreciate.
> > I am wondering how to implement below without introducing another pair
> > of SIP request/response, if you could suggest that would be great with
> > SIP compliance -
> >
> > 1. My server sending some configurations to client using SIP MESSAGE
> > 2. Client may apply some of them, so client should respond back with the
> > config that have been applied.
> >
> > Would you suggest to include a proprietary SIP header containing the
> > information to be conveyed to server ? What could be the max data a
> > header may contain ?
>
> I don't want to encourage you to use proprietary means. The most
> straightforward way would be to use a separate MESSAGE in the reverse
> direction.
>
> You *could* add a header field to the MESSAGE response. That wouldn't
> violate the rules of MESSAGE. And you could have that header field
> reference a body using a Content-ID URL (cid:). You can read about this
> in RFC5621. But you then need to find a suitable header field that
> contains a URL. (I don't recommend making up a new header field. It
> won't be valid sip even though correct implementations should ignore
> header fields they don't understand.) You might be able to use
> Call-Info with purpose=info because it is very loosely defined. In that
> case you would use Content-Type to indicate the format of your body. But
> of course you then need your own MIME-type to use for that.
>
> If this is going to be an extended conversation then it would be better
> to establish a dialog and then send your data within it. In that case
> you could use INFO (RFC6086, *not* RFC2976). Note that this still
> requires a separate request in each direction.
>
> Or, you could establish a media channel to send your data using MSRP.
>
> Or you could establish a data channel via
> draft-ietf-mmusic-data-channel-sdpneg-25.
>
> There is no theoretical limit to the size of a header field or a body.
> But once they get very big you will need a TCP or TLS connection rather
> than UDP. And sip implementations may impose some limit.
>
> Thanks,
> Paul
>
>
> > Regards
> > Abhishek
> >
> > On Sat, Apr 13, 2019 at 3:08 PM Paul Kyzivat <pkyzi...@alum.mit.edu
> > <mailto:pkyzi...@alum.mit.edu>> wrote:
> >
> > On 4/13/19 3:58 PM, abhishek jain wrote:
> > >>
> > >> Hi,
> > >> Can a Sip Response (to a Non-Dialog creating SIP Request)
> > contain a body ?
> > >> I would appreciate a quick response.
> >
> > Sometimes. The rules vary depending on the type of message.
> >
> > But not for MESSAGE. RFC3480 (section 7) says:
> >
> > A 2xx response to a MESSAGE request MUST NOT contain a body.
> >
> > Thanks,
> > Paul
> >
> >
> > >> For example -
> > >> *Server to **Client **:*
> > >> MESSAGE <server-uri>
> > >> :
> > >>
> > >> Content-Type: application/chat-info+xml
> > >>
> > >> Content-Length: ...
> > >>
> > >> <?xml version="1.0"?>
> > >> <chat-info>
> > >>
> > >> :
> > >>
> > >> </chat-info>
> > >>
> > >>
> > >> *Client to Server:*
> > >>
> > >> SIP/2.0 200 OK
> > >>
> > >> :
> > >>
> > >> Content-Type: application/chat-info+xml
> > >>
> > >> Content-Length: ...
> > >>
> > >> <?xml version="1.0"?>
> > >> <chat-info>
> > >>
> > >> :
> > >>
> > >> </chat-info>
> > >>
> > >> Regards
> > >>
> > >> Abhishek
> > >>
> > >>
> > >>
> > >>
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > Sip-implementors@lists.cs.columbia.edu
> > <mailto:Sip-implementors@lists.cs.columbia.edu>
> > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> > <mailto:Sip-implementors@lists.cs.columbia.edu>
> > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
