Re: Re: Using nist sip stack

"M. (Neo-Ranga) Ranganathan" <[email protected]> Thu, 4 Oct 2007 10:46:45 -0400
Newsgroups gmane.comp.voip.nist-sip,gmane.comp.java.woodstock.user
Message-ID <[email protected]>
Guys can we shift this discussion to the [email protected] list.

The way to associate user context with the via header would be to
define a new parameter that you use for your own purposes. Overloading
the branch id for this purpose is not a good idea IMHO. If you want
the stack to manage the transaction layer then you should let the
stack manage the branch Id. I admit that JSIP is a bit sloppy in
defining what parts are managed by user and what parts are managed by
stack. We have to tighten that up in the next rev.

Regards,

Ranga

On 10/4/07, Venkata Ramana Kunapuli <[email protected]> wrote:
> Well I  like your current interface where if user supplies "null" branch
> then stack generates it else its should keep user generated branch id except
> it should not be overwriting as it is doing now. if there is a issue with
> user generated branch id then it is user responsibility.
>
> The reason being there are tons of application out there which use SIP and
> my do some customization. even SIP RFC is using it today to differentiate
> earlier SIP RFCs with latest RFC by prepending magic cookie. there could be
> applications out there who may want to extend this further.
>
> In my case I am trying to communicate with a  server that is  restricting
> the branch id (including magic cookie part) to 32( which even I do not agree
> because it does not conform to SIP RFC,  but they are not going to change
> it). I did try to change nist jain stack ( I had only 1.2 version local
> copy) but I ran into some other issues as I posted in other thread.
>
> I am trying to evaluate the jain sip API's to see if they are useful and
> sufficient for some custom sip applications for recommendation.
>
> Thanks
> Venkat
>
> On 10/3/07, Jeroen van Bemmel <[email protected]> wrote:
> > Venkat,
> >
> > In the code I can see that the application provided branch id gets
> > overwritten. However, I'm a little hesitant to change that (cannot
> > oversee the consequences, something might break)
> >
> > To me there is no real reason for applications to generate their own
> > branch ids (I would even say it's a flaw in the API, it should be left
> > to the stack)
> >
> > Could be that the branch ID is 39 chars, it always starts with the magic
> > cookie (7 chars) so if you strip that you get your desired 32 chars
> > (which are randomly generated)
> >
> > Regards,
> > Jeroen
> >
> > Venkata Ramana Kunapuli wrote:
> > >
> > > Sorry actually it is my mistake in using that API. Display name works
> > > good. I realized right after sending the post. My bad I did not update
> > > the post.
> > >
> > > However I had issue in setting the branch name in Via header. There is
> > > API called  setBranch  to set branch ID say in Invite but when I
> > > actually create transaction using getNewClientTransaction the sip stack
> > > seems to overwrite the branch ID. and it over writes with 39 character
> > > id (max possible) while I am looking for 32 character ID. so am little
> > > uncomfortable with stack , in the sense it  does not allow me set branch
> > > nor it does not allow me set the size of branch ID.
> > >
> > > May be if there is option of setting branch size or user provided branch
> > > ID ( that will not overwritten) please let me know.
> > >
> > > Thanks
> > > Venkat
> > >
> > > On 10/3/07, *Jeroen van Bemmel* < [email protected]
> > > <mailto:[email protected]>> wrote:
> > >
> > >     Some of the TCK test cases contain similar code (for the
> displayname,
> > >     not custom via branch), and they seem to work (although not
> asserted)
> > >
> > >     When you say "I don't see the display name being added", at what
> > >     checkpoint do you mean? on the wire? or in a println? at uac/uas?
> > >
> > >     Regards,
> > >     Jeroen
> > >
> > >     M. (Neo-Ranga) Ranganathan wrote:
> > >      > Looks pretty valid. Please open up an issue and attach a self
> > >      > contained test case. I'll look into it.
> > >      >
> > >      > Ranga
> > >      >
> > >      > On 9/26/07, Venkata Ramana Kunapuli < [email protected]
> > >     <mailto: [email protected]>> wrote:
> > >      >> Thanks Ranga for the info.. I had another issue I am trying to
> > >     add display
> > >      >> name in "From" and "To" headers. I tried the following but not
> > >     successful. I
> > >      >> mean "from" header being constructed, but I do not see display
> > >     name being
> > >      >> added anywhere
> > >      >>
> > >      >>             Address fromAddress
> > >     =  addressFactory.createAddress(sipURI);
> > >      >>             fromAddress.setDisplayName("sipPhone");
> > >      >>             fromHeader =
> > >     headerFactory.createFromHeader (fromAddress, "1234"
> > >      >> /*tag*/);
> > >      >>
> > >      >> Is this not correct usage to set display name?
> > >      >>
> > >      >> Thanks
> > >      >> Venkat
> > >      >>
> > >      >> On 9/21/07, M. (Neo-Ranga) Ranganathan <[email protected]
> > >     <mailto:[email protected]>> wrote:
> > >      >>> There is no explicit support for multipart mime. You have to
> > >     construct
> > >      >>> the body by yourself and add it.
> > >      >>>
> > >      >>> Regards,
> > >      >>>
> > >      >>> Ranga.
> > >      >>>
> > >      >>> On 9/21/07, Venkata Ramana Kunapuli < [email protected]
> > >     <mailto: [email protected]>> wrote:
> > >      >>>> Hi
> > >      >>>>
> > >      >>>> I am trying to explore the nist implementation of jain-sip. I
> > >     am trying
> > >      >> to
> > >      >>>> add multipart message body but could not find right methods to
> > >     insert
> > >      >>>> multipart message body in a sip message (say INVITE). I
> > >     appreciate your
> > >      >>>> help.
> > >      >>>>
> > >      >>>> Thanks
> > >      >>>> Venkat
> > >      >>>>
> > >      >>>> example:
> > >      >>>>
> > >      >>>>
> Content-Type:multipart/mixed;bounadry=separator
> > >      >>>> --separator
> > >      >>>> Content-Type:application/sdp
> > >      >>>> .....
> > >      >>>> --separator
> > >      >>>> Content-Type:application/x-My-App
> > >      >>>> Content-Dispostion:signal;handling=required
> > >      >>>> .....
> > >      >>>> --separator
> > >      >>>>
> > >      >>>>
> > >      >>>>
> > >      >>>>
> _______________________________________________
> > >      >>>> nist-sip mailing list
> > >      >>>> [email protected] <mailto:[email protected]>
> > >      >>>>
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
> > >      >>>>
> > >      >>>>
> > >      >>>
> > >      >>> --
> > >      >>> M. Ranganathan
> > >      >>> "There are two ways to write error-free programs; only the
> > >     third one
> > >      >>> works." --  Alan Perlis
> > >      >>>
> > >      >>
> http://www.animenewsnetwork.com/encyclopedia/anime.php?id=1052
> > >      >>
> > >      >
> > >      >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > nist-sip mailing list
> > > [email protected]
> > > http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
> >
> >
>
>
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>
>


-- 
M. Ranganathan
"There are two ways to write error-free programs; only the third one
works." --  Alan Perlis
http://www.animenewsnetwork.com/encyclopedia/anime.php?id=1052