See inline.
On Apr 3, 2005 4:15 AM, Greger V. Teigre <greger(a)teigre.com> wrote:
So you have tested using avp_pushto() and it
doesn't work with stateless
replies? That's one of the things I have never tested. I'm not sure how
sl_send_reply() builds a message, but it is probably likely that it copies
fields and thus ignores (or changes) Contact. BTW, have you tried
responding to the REGISTER using t_relay() ? I have no clue what will
happen, certainly not a 200 OK, maybe an error...
t_relay() would just attempt to send the REGISTER message along. So I
don't think that is what I need.
If not, maybe you'll get
a message you can tweak with avp_*?!
But to your "real" problem: Why not create a new table called 697_location
and use save("697_location"); ?
I need to completely avoid the DB hit because for every UTstarcom ATA
we ship we would have twice the number if database hits becuase every
ATA has 2 phone port. So when we have 50,000 ATAs provisioned, there
would be 100,000 REGISTER messages being processed periodically.
Or maybe even better: you can create a
bypass when handling INVITEs and not authenticate if the caller is 697 and
just rewrite the ruri directly to your voiceprompt.
I have to reponse with a correct 200OK in order to get the ATA to give
dialtone on this port. Otherwise there is no reason for doing anything
with port 2. And with no dialtone, the subscriber will automatically
call tech support for help when they misconfigure their ATA.
g-)
Java Rockx wrote:
Greg,
I wish it were that easy. If you receive a REGISTER message, it does
contain the <Contact> header.
But by doing the following a 200 OK is retured __without__ a <Contact>
header and therefore the SIP client must ignore the response. So I
really need to find a way to "copy" the Contact header from the
REGISTER message to the 200OK response.
if (method=="REGISTER") {
sl_send_reply("200", "OK");
break;
};
FYI, if you're wondering why such a silly thing is needed it is
because we use a UTstarcom iAN-02EX ATA which is two phone ports on
the back. We only configure Line 1 and in the past this caused
customers problems because they assume the Line 1 is the "left" port
and Line 2 is the "right" port.
So the just plug in to the left port (Line 2) and realize the get no
dial tone. Then they call for support and blah blah blah.
So we now configure Line 2 as extension 697. If they attempt to dial
__any__ number from Line 2 we route them to the Asterisk server and
play a "please reconfigure your ATA" message to prevent a support
call.
The only problem is that in order for the ATA to give dial tone it
must successfully REGISTER.
And from a SIP proxy point of view, there is no reason to ever fully
process these REGISTER messages.
Regards,
Paul
On Apr 2, 2005 3:50 AM, Greger V. Teigre <greger(a)teigre.com> wrote:
> No guarantees that this works, just a quick attempt:
> You already have a Contact header in the reply (I believe), you just
> need to manipulate it. (If not, you can use
> avp_pushto("Contact/reply","avpair") to create one)
>
> Use subst to get:
> Contact: <sip:username@ipaddress:port>;q=0.00;expires=3600.
>
> Here is a regex I put together as an example:
>
/^Contact:(.*)sip:([a-zA-Z0-9_-]+)@([0-9.]+):([0-9]*)(.*)$/Contact:\1sip:\2@\3:\4>;q=0.00;expires=3600/
>
> Good luck! ;-)
> g-)
>
> Java Rockx wrote:
>> Hi All.
>>
>> I'm using ser-0.9.1 with auth_db enabled for user registration
>> stuff.
>>
>> I need to fake a REGISTRATION under certain circumstances. What I
>> want to do is sl_send_reply("200", "OK") when I get a
REGISTER
>> message from user 697.
>>
>> I don't want to actually call the save("location") method because
I
>> do not want to store 697 in the database or in ser's cache.
>>
>> So how can I sl_send_reply() and include the <Contact> header which
>> the save() function would normally insert in to the response?
>>
>> I'm thinking I could use AVPOPs somehow, but I'm not sure.
>>
>> Can this be done?
>>
>> Regards,
>> Paul
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers(a)lists.iptel.org
>>
http://lists.iptel.org/mailman/listinfo/serusers