On 4/13/19 9:31 PM, abhishek jain wrote:
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.
I doubt that this would have any appreciable affect on your network
traffic unless you are using MESSAGE is a really inappropriate way. If
your traffic is that high then you probably ought to be establishing a
direct channel for these messages.
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
<mailto:cid%3acn35t8j...@example.com>>; purpose=info
Content-Type: application/chat-info+xml
Content-Length: ...
content-ID:<cn35t8j...@example.com <mailto:cn35t8j...@example.com>>
<?xml version="1.0"?>
<chat-info>
:
</chat-info>
Why is the mailto stuff present above???
I would expect just
Call-Info:<cid:cn35t8jf02@example.com>; purpose=info
...
content-ID:<cn35t8j...@example.com>
Otherwise it looks reasonable.
Thanks,
Paul
Regards
Abhishek
On Sat, Apr 13, 2019 at 4:36 PM Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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
