Sorry, this reply didn't originally go to the whole list... I was talking about the to tag only in the context of modifying the UAC module to do this like it does From. I realize now that it's only the URI being modified so you're right, the tags don't matter.
My original concern with just re-writing the To: URI is that, strictly speaking, it's not allowed by RFC3261. Specifically section 12.2.1.1, which requires reflection of the original To: and From: URIs in subsequent requests in a dialog. If a UA sends a re-invite back upstream, it will reflect my re-written URI to the original UA, which then might not be able to match the dialog because the URI is different. I believe that is why uac_replace_from exists for the From header. The uac module catches such requests, and restores the original URI. I know of nothing that currently handles To that way. In reality, UAs fully supporting 3261 shouldn't care about the URI, and the restriction I mentioned above is only for backward compatability. Perhaps I'm worrying about nothing, but uac_replace_from must exist for a reason. Thanks, Phil On Nov 29, 2007 12:51 PM, Alex Balashov <[EMAIL PROTECTED]> wrote: > > Phil, > > Why would you have to deal with the To tag? > > I've had to do this very often and simply using textops to transform the > headers precisely as you describe has always worked. Just use regex > to conserve all the tags and other extended fields that appear in the > To and From URIs. > > -- Alex > > > On Thu, 29 Nov 2007, Phil D'Amore wrote: > > > Hi Everyone... > > > > I'm looking for some advice. Let's say I have a To: header in an > > initial INVITE: > > > > To: Bob <sip:[EMAIL PROTECTED]> > > > > Due to carrier requirements, it really needs to be: > > > > To: Bob <sip:[EMAIL PROTECTED]> > > > > I'm not asking how to do it. I know I can use some textops functions > > to make this happen. I also know that doing this might break > > something. > > > > The uac module already nicely handles the From: header in a way that > > doesn't break things. I thought about extending this to handle To:, > > but I worried that the Record-Route header might get too long for some > > UAs if I wind up having to change both headers. The To tag must also > > be dealt with somehow, which I think might make it harder to do than > > From. > > > > Using a 302 response is not an option for me, and I'm really trying to > > avoid getting a B2BUA involved with this right now. Moving from > > openser 1.1.1 to 1.3 is enough for me without changing my architecture > > ;). I'm wondering what would be the best way given what openser can > > do right now (1.3) to re-write that header that doesn't break > > anything. I'm not adverse to writing some code to make it happen if > > that is what is needed. > > > > Any ideas? > > > > Thanks, > > Phil > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : +1-678-954-0670 > Direct : +1-678-954-0671 > _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
